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ATTACHMENT TO PRE-APPEAL BRIEF REQUEST FOR REVIEW 

Applicants respectfully request the Office to reverse the decision set forth in the Office 
Action mailed December 17, 2009 based upon the clear errors described in this paper. 

1. The parameters of a standard SNMP GET request are not equivalent to a plurality 
of proposed correct values for a MIB object. 

The Examiner relies on Kekic to allegedly teach "a SNMP GET request identifying an 
SNMP MIB object and also containing a plurality of non-null values comprising proposals for a 
correct value of the SNMP MIB object." Kekic describes a standard SNMP GET request. 
However, a person of reasonable skill in the art would understand that the parameters to a 
standard SNMP GET request are not proposals for a correct value for the MIB variable 
parameter, as claimed. A standard SNMP GET request is issued for the purpose of retrieving 
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the value of the MIB object identified in the request, and the request does not include a proposal 
for the value that the request expects to retrieve. Kekic in particular does not teach or suggest 
that an SNMP GET request includes as an input parameter a proposed value for the MIB object 
named in the request. 

The Office Action cites "...snmpGet()... Col. 86 Ln. 25-46" in Kekic, which describes 

implementation of standard SNMP methods. The contents of a standard SNMP GET request are 

suggested in lines 43-46 of the cited passage which state: 

"Valid parameters such as a device name, a community string, and a MIB variable are 
required to perform these methods, otherwise a corresponding error message is given 
instead of the valid MIB value. " 

The Examiner considers the MIB variable parameter to be equivalent to the claimed SNMP MIB 

object and considers the device name and community string together as equivalent to the claimed 

"plurality of values comprising proposals for a correct value of the SNMP MIB object." 

A device name and community string are not proposed values for the MIB variable whose value 

is being requested. The device name is required to identify the relevant device, and the 

community string is a security token that allows access to the desired object. It is clearly an error 

to consider the parameters of a standard SNMP GET request to be equivalent to a plurality of 

values comprising proposals for a correct value of the SNMP MIB object. 

The Examiner appears to allege that if the value of a community string is unknown, there 

is a way to determine whether a value for the community string is valid or not using a standard 

SNMP GET request. However, Kekic does not describe an SNMP GET request in which the 

MIB variable input parameter identifies a community string. Thus, the value of a community 

string as an input parameter to the SNMP GET request cannot comprise a proposed value for the 
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MIB variable identified in the request. The value of the community string is a security token that 
is necessary to be presented for access to some other MIB variable (and not the community string 
itself). 

Even if Kekic did attempt to validate a community string value by proposing a value for a 
MIB object that is a community string, Kekic only describes a single community string input 
parameter, not a plurality of proposed values as claimed. There is no suggestion that the device 
name input parameter represents a second proposed value for the community string. 

2. A standard SNMP GET error message is not equivalent to the claimed notification. 

The Examiner relies on Kekic' s description of an error message generated by an SNMP 

request to allegedly teach "transmitting a notification message indicating whether any of the 
values matches the correct value of the SNMP MIB object. " However, an SNMP GET error 
message is not the same as the claimed notification because an SNMP error message does not 
indicate whether any of the parameters to the request match the correct MIB object value. The 
semantics of an error message and the claimed notification are very different. An error message 
is intended to signal a failure with the request, whereas the claimed notification is the expected 
response to a request conforming to the new interface described in the claims. 

As mentioned above, the Examiner appears to allege that receiving an error message in 
response to providing an invalid community string is equivalent to a notification that the 
"proposed value" for the community string is not the correct value. However, an error message 
received in response to a SNMP GET request is not a notification of whether any of a plurality 
of proposed values are correct for the requested MIB variable at least because there are not a 
plurality of proposed values in the request. 
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In addition, when the value of the community string is valid, the system returns the value 
of the requested MIB variable. The system does not transmit a notification message that 
indicates that the "proposed" community string is valid, as claimed. Also, receiving an error 
message in response to issuing an SNMP GET request does not necessarily mean that the value 
of the community string is invalid. There might be some other error in the request. Thus, 
receiving an error does not necessarily indicate that the value of the community string input 
parameter is not a correct value. 
3. Conclusions 

The Office action is based upon clear error and the rejections of all pending claims should 
be reversed. 

Respectfully submitted, 

Hickman Palermo Truong & Becker LLP 
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